Ive wrote:
> after having read the funny and entertaining thread about JPEG2000 from the
> weekend here are some observations of mine on this "future" image file format.
> I will try to give some facts and avoid too much rants and rambling, but let's
> see.
> Some weeks ago I did implement a JPEG2000/J2K decoder/encoder and did
> a lot of research on this topic, so I hope to be qualified to do some rant about
> all this...
> 
> First about the claim of the superior image quality of J2K compared to the
> conventional jpeg DCT encoding. Well, I would say it depends. For highly
> compressed images (with a ratio of lets say 1:80) it is definitely true. While
> JPG consists only of the well known ugly block artefacts, J2K gives a smooth
> but blurry image that is much more pleasant to the eye. But for less compressed
> images, when image quality is the main issue, the file size will be quite the
> same and it simply depends on the kind of image and it is also a matter of
> personal taste.
> Imagine a picture with a smooth sky gradient and some small wires in the
> foreground. JPG will introduce some artefacts (and color banding) in the sky but
> J2K will tend to blur out the wires and make them vanish - so anyway, a loss of
> information is a loss of information.
> In my opinion, the impression of getting a better image quality with JPEG2000 is
> mostly the result of the advertising of some commercial companies to point out
> the neccessarity of purchasing their product (library, plugin or whatever).
> 
> But there is also the possibility of using lossless compression with JPEG2000
> and this gives in most cases a much better compression ratio than e.g. PNG's
> zlib compression and it beats LZW (as used by e.g. TIFF) all the time. So here
> goes a clear point to JPEG2000. And I think it is also quite nice to use one
> file format that allows both, lossless and adjustable lossy compression,
> depending on your needs.
> 
> Another issue is: JPEG2000 can be streamed. This means (well, this would
> mean, in case your browser would support the format) you can view the complete
> image immediately at low quality and the quality does successive increase while
> downloading the image. Nice feature, sure. Especially for slow connections
> and/or huge images. But remember this is also possible with progressive
> encoded jpeg files but IE downloads first the complete image until it displays
> something, with non progressive jpeg's it shows them at least line by line.
> Firebird works meanwhile nicely with progressive jpeg files. How long does jpeg
> exist? Not sure, but I guess so about 15 years.
> 
> Next point: JPEG2000 supports full colorimetric information stored within the
> file. The files posted by IMBJR are an example for this, they include an ICC
> profile. Fine, but PNG, JPG and TIFF do support ICC profiles also. The problem
> is, very few applications and none of the browsers does make use of this. In
> fact, the only application I am aware of is Photoshop.
> The Gimp (and the complete linux world)  seems to be completely unaware of
> color management issues. :(
> But the funniest thing is: Windows includes (since  Windows 95 !!!) a color
> management module that would be able to handle ICC profiles. It's called ICM and
> was not developed by Microsoft but licenced from Heidelberger Druckmaschinen.
> But there is not even a Microsoft application (including IE) that makes any use
> of it. I guess the licencing devision did forget to inform the developers about
> it, or maybe they used Outlook and the mail got lost ...  enough. And I know
> nothing about the Mac.
> 
> 
> A defined file format and an ISO standard is fine but of less practical benefit
> until it is not really supported by application software, so lets have a look at
> the availability and quality of J2K en/decoders, libraries, plugins and the
> applications using them.
> 
> At first, if you do not want to trust blindly to my words or in case you want to
> test the quality of the j2k implementation of your favorite viewer/browser by
> yourself here are the official JPEG2000 test files:
> http://www.crc.ricoh.com/~gormish/jpeg2000conformance/j2kp4files_v1_4.zip
> but be warned, 50MB !
> It is so big because it contains also uncompressed TIF files as a reference.
> Note: These are only the files that are currently available to the public, there
> are more but due to some copyright issues you need to be a registered
> developer to access them.
> 
> (BTW, Thorsten or anybody else who uses a Mac, I would be very interested to
> hear something about the QuickTime J2K implementation: how many test
> images are correctly displayed and wich of them?)
> 
> There is currently only one non-commercial library available called JasPer but
> it implements only part 1 of the ISO standard (and in fact only a subset of it).
> You can find JasPer (and a list of software that uses this library) here:
> http://www.ece.uvic.ca/~mdadams/jasper/
> JasPer fails on 4 out of 9 test images.
> 
> There is one more a non-commercial j2k-library, http://j2000.org/  but it
> implements only the j2k code stream and not the JPEG2000 file format, also
> it seems to be in a state of hibernation, so I'm just ignoring it.
> 
> Then we have a wide range of commercial libraries. I do not know all of them,
> but the company I'm working for did buy 2 of them to check them out and I did
> some more tests by playin' with applications where the used library was known.
> Well, for short, the result was not very promising, most of them failed also on
> 3 to 5 images and as these are not alwayws the same they are also quite
> incompatible to each other.
> 
> In fact, the only one I would recommand is Kakadu at
> http://www.kakadusoftware.com/
> Kakadu works really fine and fails on 0 out of 9 images. To give you an idea: to
> purchase a "freeware-licence", the POV-team would have to pay 550$. The
> commercial ones go up to 12000$ which would mean nothing for a company like MS.
> And just an observation: Prof. David Taubman, the developer of Kakadu is also
> a member of the ISO for JPEG2000 and somehow it seems to me he developed the
> library first. And I have also a strange feeling when I think about the fact
> that he gets payed by public money but has no problem in selling the product he
> has developed at his work (I guess with help of his students). OK, call me old
> fashioned.
> 
> And just because it seems to be so widely used around here: IrfanView uses the
> Luratech plugin (to be more exact the former Luratech now AlgoVision because
> Luratech didn't survive) and it also fails on 4 out of 9 images. And (just a
> little rambling, I cannot resist) I always was wondering why IrfanView did
> become so popular (among the Windozers around here). For sure, it somehow
> "displays" all of the images, but some of them with simply plain wrong colors,
> and it does this without any warning or notice to the user that there might be a
> problem. This does happen also with some TIFF images (especially if they are
> not encoded in rgb color space) and even jpeg (cmyk's) and png files (ignoring
> the gamma chunck). I never liked this behaviour and I guess some of you have
> viewed images with IrvanView without ever realizing that what you see is not
> even near the way it should be. Well, enough of that.
> 
> Finally my own implementation fails on 0 out of 9 test images but it fails on 4
> out of 30 more unusual code streams - so after all it is not so bad :)
> 
> Another side note for Torsten: from a programmers point of view, implementing
> the DWT is not more sophisticated than a DCT, I have done this also a few years
> ago. In fact, en/decoding a J2K code stream is quite streightforeward. The
> JPEG2000 file header is just XML so any XML parser will do (and luckily I had
> not to write one).
> 
> 
> And about the 16bit/8bit per channel color banding controversy. Somehow this
> reminds me on people who seem to think a 64bit CPU is twice as fast as a
> 32bit one. It's not that simple and even color scientists do not share the same
> opinion about this (the 16/8bit color I mean, not the CPU ;)  If you are really
> interested look e.g. here:
> http://www.brucelindbloom.com/DanMargulis.html
> 
> 
> All this are just my 2 euro cent and it is quite possibly that some of the
> information is already outdated. The time of my research is about 4 months
> back and since then I was not much interested in the topic.
> 
> Final note: I do not care much about the file format one is posting. I can see
> JPEG2000 without problems and I have a fast connection, so everything is fine
> for me. But I really doubt the benefit of posting a JP2 file - especially a
> 16bit/channel one.
> 
> 
> so long
> -Ive
> 

talking to someone who actually i assume got work to purchase a
hardback book entitled 'jpeg2000' and their experiences, i had the 
distinct impression that the focal blur operation of povray could be 
removed, provided of course we implemented the facility of jpeg2000.
personally speaking, i can't see the point

stephen

anyone know about mozilla, newsgroups and a "don't display posts from"
option
much previous is humerous or meant to be, immediately above is serious

Post a reply to this message